系列：「從單一 agent 到多 agent 集群的開發流水帳以及應用」— Day 01

總介

一個人、多家 AI CLI，但是從土炮一顆 agent 開始：先把單一 AI CLI 馴服成能無人值守跑的東西，再讓多家不同廠牌的 AI 組成會互相把關、跨機分工的集群，最後把這整套接進自己的生活裡真的天天用。我會一直寫到我的專案真的每天在服務我為止。

先把這系列大概要做的事梳理成六條主線。這不是宣稱下面每一項今天都已經完成;Day 01 先畫地圖,後面每天都要拿程式碼、測試、失敗案例與可重跑指令來對帳。

1. 先把一顆 AI CLI 馴服成能無人值守的 agent

第一步不是多 agent,而是讓單一 agent 離開聊天視窗之後仍然可靠。系統要提供一致的互動與自動化入口:TUI 給人操作,exec 跑單輪任務,serve 啟動常駐服務,mcp 把工具交給其他 AI client,note、recall、review 則接到本機 Life Node。底層還要能用子行程或 PTY 驅動 Claude、Codex、Antigravity、OpenCode,把四套不同的參數、輸出格式與錯誤行為收斂成同一種事件。

無人值守最麻煩的不是 prompt,而是逾時、stdin、權限、退出碼與額度。每次呼叫都要有 deadline 看門狗,能分辨成功、可重試錯誤、rate limit、需要登入與必須交還人類的失敗;provider 掛掉時可以 fallback,但不能無限重試或悄悄吞錯。Day 01 的最小驗收是能重跑 spectyn --version、spectyn --help、spectyn node-capabilities 與 spectyn doctor --json,先知道自己手上的 agent 到底具備什麼能力。

2. 讓多家不同廠牌的 AI 組成會互相把關的 crew

單一 agent 穩定後,才進到 ensemble:把規劃、實作、測試、審查與落地拆成不同角色,讓 Claude、Codex、Antigravity、OpenCode 可以平行工作。排程者要知道每家目前能不能用、剩多少額度、適合寫程式還是審程式,並把任務送到合適的 provider,而不是把同一段 prompt 盲目廣播四次。

程式碼不能由產生它的 AI 自己宣告通過。落地前除了真實測試 exit 0,還要取得至少兩家不同廠牌的審查結果;任何一家提出阻擋問題就退回修改,超過回合上限則標成 needs-human。每一輪使用的模型、輸入、diff、測試結果、verdict 與駁回原因都要留下來,這樣「兩家 AI 說可以」才是可稽核的 gate,不是畫面上兩個綠色勾勾。

3. 把 agent 接成能跨機分工的 mesh

每台節點執行同一顆 spectyn binary,用 spectyn serve 開出 HTTP、WebSocket、/api/*、/rpc/* 與 /m。Tailscale 解決節點之間怎麼互相找到,HMAC 叢集認證與本機 identity key 解決「找到之後能不能相信」。敏感 RPC 必須 fail closed:沒有 cluster secret、簽章不正確或時間窗過期,就不能派工。

任務流分成兩類:inbox 傳協調訊息,backlog 保存可以被認領、重試與交接的正式工單。節點要用 capabilities 宣告自己有哪家 AI CLI、哪種模型、哪個平台與哪些工具;排程者再依能力與負載路由。驗收不只是兩台機器 ping 得到,而是能從 A 節點派任務到 B 節點、看到執行事件、收回結果,斷線或重複認領時也不會把同一份工作落地兩次。

4. 做出真的能每天操作的跨平台介面

同一套 fleet 不能只活在開發者的終端機裡。TUI 負責快速本機操作;Tauri 桌面 App 與 React 網頁版提供完整管理介面;/m 是由 daemon 直接提供的手機優先 PWA,讓我在外面也能看節點健康、任務狀態、錯誤與審查結果;手機行動殼、Termux worker 與遠端 supervisor 則處理真正的行動端情境。

各介面不能各自發明一套狀態。節點、任務、事件、審查與告警要共用同一份資料契約;重連後必須 resync,危險操作要依風險增加確認摩擦,失敗不能只顯示一個紅點。這條主線最後要在 macOS、Windows、Linux、iOS、Android 的真裝置或可驗證 build 上對帳,而不是只看設計稿。

5. 把 mesh 接進真正會每天使用的 10 個正式衛星

mesh 是底座,衛星才是它每天替我工作的地方。這 10 個專案各自解一個具體問題:

這一段的重點不是列出十個 repo 名字,而是讓它們共用 mesh 的身分、記憶、事件、審查與遠端操作能力。只有真的把資料流接起來、每天有任務在跑,衛星才不是產品型錄。

6. 補齊一套系統要長期服務人所缺的底座

最後 14 天處理的是「能跑」和「值得長期交付生活」之間的差距。記憶要從 note 真的走到可召回、可追蹤來源的 owned memory;agents 設定、對話與 memory.db 要做到靜態加密;spectyn-cortex 訓練注意力、判斷校準與工作記憶;spectyn-insight 則把睡眠、工作、學習等跨衛星資料整理成可被否證的「我」模型,而不是亂下結論。

系統也要從被動問答走向有邊界的主動介入:依事件提醒、情緒與恢復狀態提出建議,用 spectyn-soma 安排訓練與攝取,用 relations 追蹤人際承諾,依認知能量重排行程。任何對外動作,尤其財務或替人送出內容,都必須先經審批、可撤銷並留下紀錄。

收尾不是做一支漂亮 demo。我要真的產出桌面與手機 build,跑兩機 live smoke test,關掉防護重現命令注入、verdict 投毒等事故,再把文件裡的每一個宣稱和程式碼逐條對帳。Day 30 結算時,會同時列出完成的數字、仍然失敗的地方與剩餘風險。

上面六條主線,是整個系列最後要走到的地方,不是 Day 01 一天要完成的清單。要讓多家 AI 能互審、跨機派工,首先得有一個穩定而一致的共同入口。所以從這裡開始,先把鏡頭拉回最小單位：一顆 spectyn binary,以及它同時承擔的五種身分。

前言：為什麼先從一顆 binary 開始

我的桌面上常態開著四家 AI CLI:Claude Code、Codex、OpenCode、Antigravity。每一家都有自己的模型、額度、參數與脾氣,而我只有一個人。

用久之後我發現,真正的痛點不是「AI 不夠聰明」,而是人變成了匯流排:A 家寫完的程式碼,要我複製給 B 家審;B 家的意見,再由我翻譯回去給 A 家改。訂閱了四家服務,同一時間卻常常只有游標所在的那一家在工作。四個聰明的副駕駛,共用一個會累、要睡覺、頻寬還很有限的人肉排程器。

所以這一系列要做的,不是再造一個聊天介面,而是把「一個人 + 多家 AI CLI」升級成一支可以並行、互審、跨機派工,而且能留下證據的 agent fleet。

這就是為什麼 Day 01 不先談漂亮的多 agent 流程,而是從所有能力共同經過的入口開始：一顆叫 spectyn 的單一執行檔。

一顆 binary、五種身分

先看整個系列的目的地。手機戰情室、各機器上的 AI CLI、跨機 mesh 與 review-gate,最後都會連到同一套架構裡：

但這張圖一次放進了整支艦隊。Day 01 先不展開所有節點與派工流程,只把中間最關鍵的單一安裝產物放大。同一顆 spectyn binary,在系統裡同時負責五種身分：

1. 互動與自動化 CLI:spectyn 可直接開 TUI,也能用 exec 跑單輪任務;note、recall、review 則是 Life Node 的本機入口。
2. 常駐 daemon:spectyn serve 啟動 HTTP 與 WebSocket 服務,承接 /api/*、/rpc/*、/m 等介面。後端細節留到 Day 03。
3. MCP stdio server:spectyn mcp 把內建工具以 MCP 協議提供給其他 AI client。
4. 其他 AI CLI 的呼叫者:系統用子行程與 PTY 驅動 Claude、Codex、Antigravity、OpenCode。這是「AI 呼叫 AI」與 Day 02 多廠牌雙審的地基。
5. 本機信任根:同一個程式也碰觸事件加密身分與叢集認證祕密。這使部署簡單,也讓權限邊界必須更保守。

單一 binary 的好處很直接:安裝、升級與跨機部署只需要處理一個主要產物。代價也很直接:CLI、網路服務、AI 子行程和金鑰操作的攻擊面集中在一起。方便不是免費的;後面談 RPC、注入防護與全面靜態加密時,都會回到這個取捨。

五種身分只是功能邊界,不是說 spectyn 只有五條指令。每種身分都會再展開成安裝、診斷、任務、節點、認證與 provider 等操作,因此下一步要看的是這顆 binary 實際暴露了多大的指令表面。

「約 90 條指令」到底怎麼算

目前的 --help 依用途分成 Interactive、Daemon、Self-improvement、Life Node、Diagnostics、Agents、Cluster、Auth、Provider、Project 等區塊。以 2026-08-24 的本機版本來看,help 畫面有 59 列 spectyn ... 用法;其中不少列又包含 install|uninstall|status、create|list|delete|... 這類巢狀動作。把可呼叫的子動作展開後,命令入口約 90 個。

所以「~90」是描述操作表面的量級,不是承諾永遠固定在 90。最可靠的文件仍是你手上那顆 binary 的 spectyn --help。

這是本文整理時的程式碼快照:

這些數字是快照,不是品質本身。20,439 行的手寫 CLI router 尤其不是值得炫耀的勳章;它一方面讓所有入口集中、容易搜尋,另一方面也讓 dispatch 順序、help 文字和實作同步變成長期維護成本。

這次整理先踩到的坑：名稱和文件會漂移

舊稿仍寫著執行檔叫 phantom,原始碼入口也指向 core/src/bin/phantom.rs;但現在 core/Cargo.toml 登記的 binary 已是 spectyn,入口也已改為 core/src/bin/spectyn.rs。舊稿還把 Day 02 預告成單一 binary 架構篇,第九版目錄的 Day 02 則早已改成 ensemble 多廠牌 AI crew。

這不是單純換字。只要文件、help、檔名與真實行為有一處不同步,讀者就會在第一個指令失敗時失去信任。這個系列採用的規則因此很簡單：code is truth;數字要標日期,命令要能重跑,尚未完成的能力要明說。

也因為文件會漂移,Day 01 不用一大串讀者照著跑過就忘的安裝指令開場,而是先用唯讀巡覽建立當下這個版本的地圖。

今日 lab：用唯讀巡覽建立自己的地圖

這不是安裝教學;執行前請先確認 spectyn 已在 PATH 中,或用 SPECTYN_BIN 指向本機 binary。先不要啟動 daemon、派任務或修改設定;下面這支巡覽只讀取版本、help、節點能力與環境健康：

#!/usr/bin/env bash
set -u

BIN="${SPECTYN_BIN:-spectyn}"
command -v "$BIN" >/dev/null || {
  echo "找不到 $BIN;請先安裝 spectyn 或設定 SPECTYN_BIN" >&2
  exit 1
}

echo "== 版本 =="
"$BIN" --version

echo "== 節點能力 =="
"$BIN" node-capabilities

echo "== 指令表面 =="
help_text="$("$BIN" --help)"
printf '%s\n' "$help_text"
printf '\nhelp 中可見的 spectyn 用法列數: '
printf '%s\n' "$help_text" | grep -c '^  spectyn'

echo "== 環境健康 =="
if ! "$BIN" doctor --json; then
  echo "doctor 找到待處理項目;這是診斷結果,不是巡覽腳本壞掉。" >&2
fi

驗收時不要只看最後是不是綠燈。你應該能回答:

• 目前跑的是哪個版本與 build?
• 這台節點看得到哪些工具與能力?
• help 的功能區塊是否和你的使用情境相符?
• doctor 報出的缺口是環境問題、設定問題,還是產品問題?

今天的頭條數字是：1 顆 binary、5 種身分、約 90 個命令入口。 更重要的是,每個數字都有一條可以自己重跑的驗證路徑。

小結與明日預告

今天把整個系列的地基攤開了:spectyn 不是只有聊天介面的 CLI,而是一顆同時扮演操作入口、daemon、MCP server、AI CLI 呼叫者與信任根的 binary。它讓一個人有機會調度四家 AI,也把多種權限與攻擊面集中到同一個地方。

之後幾天應該會把spectyn CLI 做深做透的內容邊做邊介紹，直到使用者能安裝跟使用了再跳到下一階段